\subsection{Architecture}
Tagapastry system has been divided into a few packages, each of them grouping
responsibilities of different classes. These packages have been further grouped
into two folders, namely \textit{src} and \textit{test} in order to enable 
package visibility for testing classes.
Below we present list of packages in our system with a short description.
Please note that all the packages mentioned below are prefixed with 
dk.itu.samd.group2 name:
\begin{itemize}
\item .tagapastry 
\\Contains main classes responsible for proper functioning of the system
\item .tagapastry.indexing 
\\Contains classes responsible for index expansion and retraction strategies
\item .tagapastry.messages 
\\Includes all the possible message types in our system
\item .tagapastry.messages.forwardStrategies 
\\Contains classes implementing different approaches to message forwarding between nodes
\item .tagapastry.util 
\\Util package contains a few classes used for testing purposes, node ID generation etc.
\item .tagapastryClient 
\\Contains classes implementing client part of the system.
\end{itemize}

\subsubsection{Tagapastry package}
Central package in our implementation is called
\texttt{dk.itu.samd.group2.tagapastry}. It not only extends required by FreePastry 
\texttt{Application} class but it also exposes two interfaces namely \texttt{Tagapastry} and \texttt{TagapastryClient} to the future clients of our system. It also separates
most of the data types that are used in the system.

\subsubsection{Indexing package}
Indexing package includes classes and interfaces responsible for implementation of a logic 
related to expansion and retraction of indexes. These classes, implement certain
interfaces that contain only a single method, so the distribution and / or retraction
behavior can be easily overriden, up to certain degree. 

\subsubsection{Messages package}
As described in section \ref{sec:messaging} communication between nodes happens
with the usage of messages. We have grouped these messages into *.messages package.
Presently we differentiate between 14 messages and each of them, contains logic
implements certain behaviour of the system, thus any modifications and further
extensions should start from this package.
Extensibility, is not difficult to achieve. The idea is to create a new message type
which implements certain methods from a TagapastryMsg class.

\subsubsection{Forward strategies package}
The purpose of this package is to provide different implementations of the 
\texttt{ForwardStrategy} interface. This interface requires from implementors definition of a
\texttt{forward} method which specifies message forwarding strategy between different
nodes. Definition of this interface has been show below:

\begin{lstlisting}
public interface ForwardStrategy {
	public void forward(Vector<IndexRelative> children, TagapastryImpl tagaImpl, IndexMsg msg);	
}
\end{lstlisting}

Currently, we provide only two implementations of this interface namely 
\textit{SingleReturnToParentStrategy} and \textit{MulticastReturnToOriginatorForwardStrategy}.
Objects of the first class are used by tag and untag messages, however, objects of the
second class are used by a search msg.

\subsubsection{Util package}
Util package contains a few classes that either encapsulate piece of information or are
used for supplying our system with necessary data. An
example of a class is \texttt{TitleGenerator} that can compute hash value based on object title. 
Another usage involves representation of node information, that should be synchronized
among leaf set. This is represented by the NodeStatistics class. 

\subsubsection{Client package}
Client packages contains a class implementing \texttt{searchResultsDelivery} method from
a TagapastryClient interface. Implementation of this method is provided up to the end
user willing to use our system as a 3rd party component. This class also provides a starting
point from which the whole peer to peer network and the total behaviour of the system
can be simulated.

\subsection{Test architecture}
Architecture of a test subsystem has been divided into the same packages as for the
core system, however, special attention should be paid to the \texttt{tagapastryClient} package.
Its main responsibility is to separate test classes responsible for correctness and
performance testing from the classes carrying basic component testing. It contains also
a few other classes like for instance \texttt{MessageCollector} class, which is capable
of collecting information, from every node, regarding properties like total number of bytes
sent per node or total space usage by all indexes.

\subsection{Application programming interface}
An application programming interface exposed by our system is contained within two interfaces
Tagapastry and TagapastryClient. TagapastryClient has been described while describing client
package in the 8.1.6 section, so we skip it here, instead we focus on declaration of the selected methods from the Tagapastry interface:

\begin{lstlisting}
public boolean tag (String tag, String tagType, String obj);
public boolean untag (String tag, String tagType, String obj);  
public void search (String tag, String type);
\end{lstlisting}

Both tag and untag methods are the same in terms of declaration. As a first parameter
they expect, actual tag name under which certain object will be stored. The second
parameter requires the client to supply type and finally the last parameter needs to
obtain a reference to an object that should be stored in the network. An example execution
call could look like the one below:

\begin{lstlisting}
TagapastryImpl taga ; // Here obtain a reference to the class implementing mentioned interface.
taga.tag("Black Comedy","play","blackcomedy.dvd");
taga.tag("Black Comedy","genre","what_is_black_comedy.txt");
\end{lstlisting}

Searching calls are simpler as they only require search query and type of query for instance:

\begin{lstlisting}
TagapastryImpl taga;
taga.search("Black Comedy","play");
taga.search("Black Comedy","genre");
\end{lstlisting}

As we can see on the listing above, search method allows specifying not only single keyword queries
but also multi keyword queries. Interesting would be to see in the further work, search queries involving basic and complex boolean expressions, but this is out of scope for the current project.
